A number of different device management platforms exist including, for example, Dell's Cloud Client Manager. These device management platforms can allow a number of different types of devices, including, for example, thin clients, zero clients, tablets, and smartphones, to be monitored and managed from a single location (i.e., from a management server in the cloud). To allow this monitoring and management, a device agent is installed on each device so that the management server can communicate with the device agent to implement a desired type of monitoring or management. Such devices will hereafter be referred to as “managed devices.”
Sometimes, it may be desirable to update a managed device. To do so, an administrator will typically employ a user interface of the management server to specify which device(s) to update and which update to supply to the device(s). While being updated, the managed device will oftentimes experience some downtime, especially in cases where the update is a new image. For this reason, an administrator may oftentimes schedule the deployment of an update after hours or over the weekend so as to not limit a user's productivity.
Because the update command is transmitted over the network to the managed device, it is necessary that the managed device be turned on in order to receive the update command and, in response, initiate the update. However, many managed devices are configured to transition into a sleep or other lower power state after a certain period of inactivity (e.g., ten minutes). Therefore, if an update is scheduled to be deployed outside of typical work hours, it is likely that the target managed device(s) will not be awake when the update command is transmitted. In this scenario, the managed device typically will not receive the update command and initiate the update until the user returns to work and awakens the device. As a result, the update will be deployed while the user is trying to work thereby thwarting the administrator's intentions to deploy the update after hours.
Wake-on-LAN (WoL) is an industry standard protocol for waking computers from a lower power mode. To implement WoL, the network card of the device must be powered so that it can monitor for a “magic packet.” The magic packet is a broadcast frame that includes a payload of FF FF FF FF FF FF followed by sixteen repetitions of the target device's MAC address. When the network card receives a magic packet, it can cause the device to turn on.
Because WoL works at the data link layer (i.e., because it employs MAC addresses), the sender of the magic packet must be on the same LAN as the device to be awakened. More particularly, because the device to be awakened is not executing, it will not have an IP address to which a magic packet can be routed. However, various techniques have been developed to allow a magic packet to be sent to a device over the internet. For example, a UDP packet containing a magic packet in its payload can be sent from a WoL utility over the internet towards the device to be awakened. When the router on the device's LAN receives the UDP packet, it can be configured to implement port forwarding to thereby broadcast the UDP packet over the LAN. The NIC of the device would therefore receive the packet and can examine its payload for a magic packet containing the NIC's MAC address. Although this technique enables WoL over the internet, it requires the router to be specifically configured to properly route WoL packets. Such configuration can create security concerns (e.g., by creating a hole in the firewall) and is therefore not desirable.